Overview

This PR improves WiFi/TCP handshake-stall recovery so the app and underlying transport do not get stuck in different connection states.

Previously, if the handshake stalled after its retry window, recovery could leave the app-level connection state and underlying transport out of sync. For TCP, the transport could remain active while the UI reported a disconnected state. In that situation, selecting the same node again could be ignored because the radio service still saw the same selected address and an already-running transport.

This PR adds a targeted transport restart path for stalled handshakes. When recovery is needed, the connection manager first moves app state to Disconnected, then asks the radio service to restart the active transport. The fresh transport Connected signal can then re-enter the normal handshake flow.

Follow-up WiFi testing also showed that some failed TCP/USB handshake attempts could sit in a loading state until the lower-level TCP timeout recovered them. This PR adds a TCP/USB-only fast handshake watchdog so those stalled handshakes recover sooner, while leaving BLE's longer handshake timing unchanged.

Additional BLE testing exposed a separate post-handshake stuck-connecting path. Once firmware sends NODE_INFO_NONCE, the handshake watchdog is intentionally cancelled before local NodeDB install work begins. If that local NodeDB install fails, the app can otherwise remain in Connecting with no active watchdog. This PR now recovers from NodeDB install failure by routing through the same reconnecting transport-restart path.

This PR also adds defensive recovery hardening so a crashing or repeatedly failing node is not re-driven indefinitely. Recovery now uses clean transport restart only, applies exponential backoff between repeated attempts, and surfaces a sticky error after repeated unsuccessful recovery cycles.

Addresses: #3727

Key Changes

Handshake Recovery

• Adds RadioInterfaceService.restartTransport() for silent recovery of stalled mesh handshakes.
• Updates MeshConnectionManagerImpl so retry-exceeded handshake stalls request a transport restart instead of only changing app-level state.
• Adds MeshConnectionManager.recoverPostHandshakeFailure() so NodeDB install failures after firmware handshake completion use the same app-level disconnect-before-restart ordering.
• Adds a 12s TCP/USB-only fast handshake watchdog for Stage 1 and Stage 2.
• Resets the fast watchdog only on meaningful handshake progress.
• Cancels the Stage 2 watchdog synchronously when NODE_INFO_NONCE arrives, before async NodeDB install work begins.
• Adds a one-way handshake-complete latch so late progress packets cannot re-arm the watchdog after firmware handshake completion.
• Recovers only from pre-Connected NodeDB install failure; post-Connected analytics / side-effect failures are logged without forcing recovery.
• Orders recovery so the app-level Disconnected transition happens before transport restart emissions.
• Runs recovery work in a sibling coroutine so the restart sequence is not lost when the existing handshake timeout job is cancelled.
• Re-checks the current app state before recovery so a late-arriving successful handshake is not restarted unnecessarily.
• Uses atomic watchdog swaps so concurrent re-arms cannot orphan timeout jobs.

Recovery Hardening

• Removes the same-session want_config retry path.
• Uses clean transport restart for stalled recovery on both fast transports and BLE retry-exhausted paths.
• Adds exponential backoff between consecutive recovery attempts.
• Adds a consecutive recovery cap.
• Surfaces a localized sticky error after repeated unsuccessful recovery attempts instead of silently looping forever.
• Resets the recovery failure counter after successful handshake completion.

Transport Restart Behavior

• Implements SharedRadioInterfaceService.restartTransport() as an in-place stop/start of the currently active transport.
• Preserves the selected device address and existing connection intent.
• Emits a transient DeviceSleep transport transition before restarting so observers can see a real state change before the fresh Connected event.
• Keeps recovery quiet from the user's perspective by avoiding a permanent transport Disconnected event and avoiding a user-facing error.
• Skips restart when:
  • the user explicitly disconnected,
  • the selected device was cleared,
  • no valid selected address exists,
  • no transport is currently running,
  • another restart or liveness recovery is already in progress.

Handshake Progress

• Tracks meaningful Stage 1 progress from MyNodeInfo, local metadata, file info, device config, module config, channels, DeviceUI config, and early NodeInfo.
• Tracks Stage 2 progress from NodeInfo packets.
• Buffers early NodeInfo received during Stage 1 so it is not lost before the node-list phase starts.
• Keeps Stage 2 completion gated on NODE_INFO_NONCE.

Connection UI

• Adds a transient Reconnecting… state while silent handshake recovery is in progress.
• Keeps transient TCP/USB handshake recovery from looking like a final user-facing disconnect.

Test Coverage

• Adds MeshConnectionManagerImplTest coverage for:

  • Stage 1 config handshake stall recovery,
  • Stage 2 node-info handshake stall recovery,
  • TCP/USB fast recovery timing,
  • meaningful progress resetting the fast watchdog,
  • no fast recovery for BLE,
  • no restart when the handshake completes normally,
  • recovery ordering so app disconnect is processed before restart emissions,
  • post-handshake failure recovery using the same disconnect-before-restart ordering,
  • exponential recovery backoff,
  • consecutive recovery exhaustion surfacing a sticky error,
  • successful handshake completion resetting the recovery counter.

• Adds MeshConfigFlowManagerImplTest / MeshConfigHandlerImplTest coverage for:

  • meaningful handshake progress signals,
  • early NodeInfo buffering,
  • Stage 2 completion behavior,
  • watchdog cancellation when NODE_INFO_NONCE arrives,
  • NodeDB install failure triggering post-handshake recovery,
  • post-NodeDB analytics / side-effect failures not forcing recovery after Connected.

• Adds SharedRadioInterfaceServiceLivenessTest coverage for:

  • active transport restart creates a fresh transport,
  • restart is a no-op after explicit disconnect,
  • restart is a no-op after device deselection,
  • selected address is preserved,
  • restart does not emit permanent Disconnected,
  • restart does not emit a user-facing connection error,
  • restart coordinates with in-flight liveness recovery,
  • restart does not bypass environmental recovery when the transport was already stopped.

• Adds Connections UI/ViewModel coverage for:

  • transient Reconnecting… mapping.

Follow-up

This PR addresses the Android-side handshake-stall recovery path associated with the reported WiFi/TCP reconnect behavior.

During testing, this also uncovered a firmware-side crash triggered by repeated or re-entered config/node-list startup on firmware build tbeam / v2.7.25.104df5f. The firmware-side fix is being tracked separately in meshtastic/firmware#10754. This PR adds app-side defensive depth so Android does not keep re-driving a node that repeatedly fails recovery.

If field logs still show periodic TCP reconnect or configuration loops after this lands, a follow-up investigation should look at TCP idle-timeout behavior and add privacy-safe disconnect-reason logging for EOF, IOException, write failure, and idle timeout.

I mostly run nRF52 devices over BLE, so I do not have a strong baseline for long-term WiFi behavior. I tested these changes with WiFi-connected ESP32 devices while reconnecting, scanning, and disabling/re-enabling WiFi. I also tested the post-handshake recovery and recovery-hardening changes on my BLE device after the T1000-E stuck-connecting behavior surfaced during review.